암달의 법칙

2025/12/18

"일 잘하는 엔지니어의 생각 기법"의 많은 챕터들을 "암달의 법칙"으로 해석할 수 있다.

흔히 암달의 법칙은 하드웨어를 더 많이 투입해도 성능 향상이 체감한다는 법칙인데, 오늘날의 컴퓨팅 환경은 매우 복잡한 탓에 더욱 다양한 상황에서 이게 그거라고 대충 우길 수 있다.

1. 스파크 병렬 작업에서 코어 수를 늘렸지만 코어 간 주고 받고 나누고 합치는 비용이 폭발적으로 증가하여 성능 향상이 원하는 만큼 생기지 않을 뿐더러 비용 대비 효용이 적거나 오히려 감소한다. 재수 없는 경우 원래 속도보다 느리다.
2. 멀티프로세싱의 워커 수를 늘리면서 공유 자원에 대한 락 대기가 폭증하여 워커들이 뱅뱅 도는 것 같은데 성능 향상도 별로 없고 구조만 복잡해서 디버깅도 어렵고 에라이 모르겠다.

암달의 법칙과는 결이 다른 몰빵 문제는 이런 것이 있다.

1. 상호 의존이 적은 "거의" 독립적인 분할 정복 병렬 작업인데도 불구하고 단일 워커가 일을 몰빵으로 하고 있어 대부분의 워커가 놀고 있다. 데이터 스큐 문제.
2. L4 구성을 했지만 세션 성향 정보의 유지를 위한 설계가 있고 그에 따라 스티키 의존성이 발생하여 특정 데이터 흐름이 몰빵으로 흘러가고 있다.

암달의 법칙을 충분히 이겨내는 예제로는 이런 것이 있다.

1. 래빗 MQ는 고가용성 병렬 처리 금수저라는 얼랭으로 만들었다.
2. 에라이 어차피 암달의 저주를 받을 텐데 레디스는 1턴 처리를 극단적으로 빠르게 만들어서 싱글 코어로 고성능을 아묻따 암달이 뉘신지를 시현한다.

여기서부터는 사실과 다르거나 나의 편견이 섞인 의견이다.

클라우드나 빵빵한 온프레미스 환경의 축복으로 많은 개발자들이 컴퓨팅 자원을 무한으로 여기는 경향이 있다. 느려요. 느린 이유는 우리가 돈이 없어서 그래요는 대부분 사실이 아니다. 수많은 CPU는 놀고 있으며 IO와 락 블로킹만 뺑이를 치고 있다. 구조는 복잡하고 병렬성, 동시성, 동기화를 위해 숨이 막힌다. 아니 사실 우리는 이미 병렬성과 동시성을 구분하지 않고 동기냐 비동기냐만을 따지며 숨이 막히는대신 프레임워크 오토매틱의 시대에 살고 있다. 사실 나는 그게 더 복잡하다.

한 편으로 CPU 코어가 1개인 상황에서 슈도 병렬성(지금 대충 만든 단어다)을 구현한다고 가정하면 다른 관점을 얻을 수 있다. CPU 코어가 1개라도 슈도 병렬성이 고성능을 가져오는 경우는 흔하다. 예컨데 IO 치느라 CPU가 놀고 있다면 흔한 1생산자(IO) - n소비자(연산)로 병렬성을 구현하면 CPU를 더 많이 사용하고 유사 병렬성을 구현할 수 있다. 어..? 그냥 쿠버네티스 쓰고 있는데 뭔 개솔이세요. 우리는 1 코어 1 컨테이너 포그라운드 워커입니다만... 아.. 쏘리..

멀티 코어 구성이고 극단적으로 짧은 동기화 블로킹만 필요한 상황이며 사용 코어 갯수에 대한 계획이 잘 설계되어 있는 구조라고 가정하자. 이럴 때는 싱글 코어에서 금기시하던 스핀락을 쓸 수 있다. 굳이 IPC로 난리를 치지 않아도 고성능 동시성을 구현할 수 있다. 하지만 설계가 어긋나 모든 코어가 스핀락 대기를 해야 하는 상황이라면? 이제 싱글 코어때 금기시한 스핀락의 함정에 빠진다. 상황 파악을 잘해야 통제가 가능하다.

쓰다보니 내가 뭘 안다고.. 고만하자.

[t:/] is not "technology - root". dawnsea, rss